Software Vault: The Diamond Collection/The Diamond Collection (Software Vault)(Digital Impact).ISO/cdr16/tc15_023.zip/TC15-023.TXT

Text File | 1995-01-22 | 26KB | 659 lines

TELECOM Digest     Tue, 10 Jan 95 14:24:00 CST    Volume 15 : Issue 23

Inside This Issue:                          Editor: Patrick A. Townson

    Re: Noise Introduced by Bit-Robbing? (Wally Ritchie)
    Re: Chatter Heard on Scanner Leads to Criminal Charges (Michael
Deignan)
    It is Legal to Modify Receivers (Ed Mitchell)
    Re: New Alert - 911 Access (Wayne Huffman)
    Re: New Alert - 911 Access (Gerald Serviss)
    800 Numbers From Overseas (Robert Hall)
    Re: Cellular Phone Technology (Wally Ritchie)
    SS7 ISUP to SS7 TCAP Conversion (Fernando Vicuna)
    Planning to Purchase a Voice Mail System (Paul Hebert)
    Re: Video Servers (Wayne Huffman)
    Re: DQDB and SMDS (Fred R. Goldstein)
    Re: Source Code For Audio-Voice Modem Programming? (Russell
Nelson)
    Biographies/Sketches of Our Participants (TELECOM Digest Editor)

TELECOM Digest is an electronic journal devoted mostly but not
exclusively to telecommunications topics. It is circulated anywhere
there is email, in addition to various telecom forums on a variety of
public service systems and networks including Compuserve and America
On Line. It is also gatewayed to Usenet where it appears as the
moderated
newsgroup 'comp.dcom.telecom'.

Subscriptions are available to qualified organizations and individual
readers. Write and tell us how you qualify:

                 * [e-mail] *

The Digest is edited, published and compilation-copyrighted by Patrick
Townson of Skokie, Illinois USA. You can reach us by postal mail, fax
or phone at:
                    9457-D Niles Center Road
                     Skokie, IL USA   60076
                       Phone: [phone]
                        Fax: [phone]
  ** Article submission address only: [e-mail] **

Our archives are located at lcs.mit.edu and are available by using
anonymous ftp. The archives can also be accessed using our email
information service. For a copy of a helpful file explaining how to
use the information service, just ask.

**********************************************************************
***
*   TELECOM Digest is partially funded by a grant from the
*
* International Telecommunication Union (ITU) in Geneva, Switzerland
*
* under the aegis of its Telecom Information Exchange Services (TIES)
*
* project.  Views expressed herein should not be construed as
represent-*
* ing views of the ITU.
*
**********************************************************************
***

Additionally, the Digest is funded by gifts from generous readers such
as yourself who provide funding in amounts deemed appropriate. Your
help
is important and appreciated. A suggested donation of twenty dollars
per
year per reader is considered appropriate. See our address above.

All opinions expressed herein are deemed to be those of the author.
Any
organizations listed are for identification purposes only and messages
should not be considered any official expression by the organization.
----------------------------------------------------------------------

From: [e-mail]
Subject: Re: Noise Introduced by Bit-Robbing?
Date: 10 Jan 1995 14:34:39 GMT
Reply-To: [e-mail]


In <[e-mail]>, Tim Gorman <[e-mail]>
writes:

> [e-mail] (sohl,william h) writes in TELECOM Digest V15
#11:

>>> In <[e-mail]>, [e-mail] (Christian
>>> Weisgerber) writes:

>>>> What kind of noise/distortion does American-style bit-robbing
cause to
>>>> voice band signals transmitted through PCM channels?

>>> In the U.S., most intermachine trunks are common channel direct
>>> connections so only the robbed bit at each end of the IC/EC
connection
>>> introduces the robbed bit (as well as ny non CCS systems in the
EC).

>> Today, most end-to-end voice connections do not include any
trunking
>> which uses robbed bit signalling.  The great majority of local
>> trunking, especially in metro areas, has all been converted to CCS.

>> One way to determine the probability of what type of local trunking
is
>> in your area is if caller ID is available.  If you can have caller
ID,
>> then the local trunking is using CCS and thus no robbed bit
signaling
>> is involved at that end of any connection.

> This is probably a little misleading. While the robbed bit signaling
was for

> use in per-trunk signaling for passing supervision information,
merely
> converting to SS7 signaling (i.e. making caller id available)
doesn't
> automatically make the robbed bits available. This also requires
conversion
> to B8ZS/ESF signaling.

> I think you will find lots of places that have converted to SS7
still
> have the older AMI/SF facilities in place thus limiting circuit
bandwidth
> to 56kb.

Lets beat this horse one more time and see if we can keep him down for
awhile :)

1. An end to end connection will be clear channel IF AND ONLY IF all
transmission facilities (and switches) connected in tandem are clear
channel. This includes the EC local loops, the EC/IC trunks, and the
IC network (or the international equivalents).

2. T1 is clear channel ONLY if it is B8ZS. However, a B8ZS facility is
NOT NECESSARILY clear channel. Any B8ZS facility that uses D4 or ESF
signalling WILL NOT BE CLEAR CHANNEL on the channels that use D4 (AB)
or ESF (ABCD) robbed bit signalling. (European E1's, on the other hand
are always clear channel).

3. USING SS7 or any other CCS system does NOT IMPLY that AMI
facilities
cannot be used. The fast majority of EC/IC connections are AMI and
therefor not clear channel EVEN WHEN SS#7 is used on the trunk group.
The main reason for this is that the installed base of AMI trunking is
just too large. There is no pressing need to replace all AMI
facilities
with B8ZS. CCS does not imply Clear Channel. Clear Channel, however,
implies either CCS or other or some other form of signalling other
than robbed bit.

4. The trend is to use B8ZS for new facilities. AMI facilities will be
converted as necessary (not just for fun) to meet the demand for ISDN
clear channel switched calls. There is no way to obtain any kind of T1
subscriber connection to an EC that does not use robbed bit signalling
unless you count PRI (which is still a dream for the most part).

5. Even if ISDN were to eventually account for 50% of calls, there
would still be no justification to replace existing AMI IC/EC
facilities that are fine for the non-ISDN subscribers.  A regulated
carrier that tried to do this would be subject to charges that it was
trying to inflate its rate base.

6. As a practical matter, you get clear channel ONLY with ISDN and
only with bearer classes of service that are clear channel. Otherwise,
the robbed bits is gonna get you unless you are extremely lucky.
(Fortunately the effect is relatively small).

7. If I got ISDN, why would I be screwing around with modems anyway.
To interwork is the only reason and that means I am coming from clear
channel to the robbed bit world unless I'm very lucky (which I'm not).

8. Finally, an AMI intermachine channel, through not strictly clear
channel
(due to Zero Byte Suppression) is effectively clear channel for modem
transmission when robbed bit is not used (i.e. CCS). This is because
there
is no need to ever transmit the signal level encoded by the zero
octet.


Wally Ritchie   Ft. Lauderdale, Florida

------------------------------

From: [e-mail] (Michael P. Deignan)
Subject: Re: Chatter Heard on Scanner Leads to Criminal Charges
Date: 10 Jan 1995 14:34:14 GMT
Organization: The Ace Tomato Company


In article <[e-mail]>, [e-mail]
(Tony Pelliccio) writes:

> Of course if you really want to follow a cell call just get a DDI
and
> hook it up to your PC. The interesting thing is that the company
that
> sells the DDI will only release software with ESN capability to law
> enforcement people. Makes you wonder doesn't it?

Actually, the software that comes with every DDI has the capability of
displaying ESNs. You just make a few minor software patches to the
executable. Not that *I* would ever do such a thing, mind you.


MD

------------------------------

From: Ed Mitchell <[e-mail]>
Date: Tue, 10 Jan 95 08:37:36 PST
Subject: It is Legal to Modify Receivers


Pat writes in reply to Bill Sohl's FAQ on Cellular and Cordless
telephone monitoring:

> Aside from what the Electronic Commuications Privacy Act says, the
> Federal Communications Commission addresses the question of radios
> which have been modified.  Illegal modification (i.e. modification
by
> an unlicensed person) voids your FCC authority to operate the radio.

Pat this is not true at all except for transmitters. You do not need a
license to operate a receiver (If you have one, I'd like to see it!).
You do not need any certification to modify a receiver. There are no
laws prohibiting your own modification or maintenance of your own
receiving equipment. The only thing that self-modification does is to
void your warranty. If someone wishes to make modifications for any
number of purposes, often legitimate and not merely for scanning
illegal frequencies, there are many BBS, online services and Internet
sites that have files on modifying nearly every radio or transmitters
or transceiver ever built.

In addition to the millions of existing scanners that receiver these
frequencies, many will remember that the cellular frequencies were
carved out of what had been television specturm (channels 71 to 83 of
the UHF spectrum). Such televisions and VCRs (with built in tuners)
continued to be sold until the late 1980s. Such TVs can very much be
used to receive cellular frequencies by tuning with the fine tuning
control through the old channels. Before it was illegal to do so, I
did use a common TV to tune through and intercept cellular calls just
to prove how silly was the then proposed prohibition on the sale of
cellular recievers. Because estimates suggested there were over 100
million such tuners capable of receiving cellular phones coupled with
the gradual phase in of digital networks, I believed then that the
legislation concerning the sale of cellular receivers should have been
declared moot. There are too many receivers out there now -- digital
networks are being deployed now and their deployment will soon
accelerate. New technology will obsolete the need for the legislation.


Ed Mitchell  [e-mail]
[e-mail] tcp/ip packet net

------------------------------

From: [e-mail] (Wayne Huffman)
Subject: Re: New Alert - 911 Access
Date: 10 Jan 1995 12:13:15 GMT
Organization: Netcom


In <[e-mail]> [e-mail] (Mjsutter) writes:

> This is a good idea. However, it could be at odds with another good
> idea which is that the cell ID that the caller is using be passed
> through the cell switch to the tandem so tha the 911 database can
use
> the cell ID as an approximate location of the caller. In metro areas
> the size of the cell would be very small indeed. Less that a year
ago
> a life would have most likely been saved in Rochester N.Y. if this
> capability had been available.

This reminds me of a time when I was an AT&T Account Executive working
in my sales territory near the Capitol and Union Station in
Washington, DC.
I was about to be mugged outside a fast food place, and I dialed 911
from my (Bell Atlantic Mobile) cell phone. I was connected to the 911
dispatcher in Arlington, VA! They were able to connect me back to DC,
but I was quite surprised to get Virginia, when I was in the middle of
DC. I hope they can get this straightened out for good.


Wayne Huffman


[TELECOM Digest Editor's Note: So when you reached the DC police did
they
respond in a timely manner to keep you from getting mugged?  When they
arrived, did they arrest you for bothering them? :)  Were you able to
identify the mugger? Did he by chance resemble Mayor Berry? :)  How
are
things in Our Nation's [Drug Sales and Murder] Capitol these days,
anyway?
Did the mugger steal your cellular phone as well?    PAT]

------------------------------

From: [e-mail] (Gerald Serviss)
Subject: Re: New Alert - 911 Access
Date: 10 Jan 1995 17:02:19 GMT
Organization: Cellular Infrastructure Group, Motorola


In article <[e-mail]>, Mjsutter <[e-mail]>
wrote:

> Jim Conran writes:

>> In addition, the FCC should require all cellular phones to be
>> equipped to access the strongest cellular base station signal when
911
>> is called.  Finally, the FCC should make the 911 provision an issue
as
>> it currently reconsiders cellular license renewal applications.

> This is a good idea. However, it could be at odds with another good
> idea which is that the cell ID that the caller is using be passed
> through the cell switch to the tandem so tha the 911 database can
use
> the cell ID as an approximate location of the caller. In metro areas
> the size of the cell would be very small indeed. Less that a year
ago
> a life would have most likely been saved in Rochester N.Y. if this
> capability had been available.

I theory, 911 access for cell phones is a good idea. The problem is
reducing that theory to practice.

Let's consider a metro area as the previous poster suggests. In our
most dense operations that I am familiar with the smallest cell radius
is 500 meters. This gives an area of 785,000 meters-square or about
.25 miles-square.  If you consider that in a metro area where this
cell would be located is built up and that the average number of
floors covering this area is just say four (source ... PFA) you have
one square mile of area that this caller could be located in. Even if
we include information on the sector of the origin of the call we are
down to .33 or .16 square miles of area. Compare this to the typical
911 call from a land phone which can isolate the caller to a specific
location (home, office, payphone ...) and you can see that the
information that a cellular system can provide currently is hardly
useful for delivering a 911 call to the proper dispatch center.

In a suburban setting where there are lots of jurisdictions and cell
placement and thus coverage is dictated by traffic patterns there are
just as many problems. The use of the strongest signal is no guarantee
of routing the call correctly, especially if you are in a building.
The closet cell may have its line of site thru a wall and the next
closet thru a window. In this case the location data is even less
useful.

Sure we could add GPS receivers and exact positioning information to
the 25 million cell phones in use in the US, of course, you would also
have to replace or modify all the fixed equipment in all the systems
to use that information and the the air specs would have to be
updated.

And we thought that rolling out digital service was a hard problem to
solve. It pales by comparison with this problem ;-)

I think that the FCC exemption is based on good engineering and the
realization that today we do not have the capability to locate the
caller easily, if at all.


Jerry Serviss   Motorola Inc   [e-mail]

------------------------------

Date: Tue, 10 Jan 1995 22:41:29 HKT
From: Mr Robert Hall <[e-mail]>
Subject: 800 Numbers From Overseas


Judith Oppenheimer and Ari Wuolle have both discussed the fact that it
is now possible to access U.S. 800 numbers from international
locations.
Following Judith's dialing suggestions, I attempted to call a number
of 800 numbers from Hong Kong.  For example, I dialed:

011                 International Access Code
   1                Country Code for U.S.
     800-555-1212   800 Directory Assistance

The call appears to have been processed by the Hong Kong switch, but I
get a recording in a very American voice telling me:

"access to the 800 number you have dialed is not free when dialed from
outside the United States.  If you proceed with this call, you will be
billed international direct dial rates for this call.  If you do not
wish to proceed with this call, hang up now".

So, I wonder if the assumption that it's up to my local IDD provider
to just turn on access to U.S. toll-free numbers is, in fact correct,
or whether the U.S. 800 service provider has a say in the deal as
well.  Are there all of the usual tariff negotiations between the
carriers?

What about calls from the U.S. to other countries' toll-free numbers?
Since Hong Kong is a small country and local calls are free, the use
of 800 numbers here has been pretty much limited to accessing a
particular foreign carrier's "home direct" service.  For example, from
within Hong Kong, I dial 800-1111 to get the AT&T "bong" to place
calls charged to my AT&T card.  If someone Stateside dials
011-852-800-1111 do they loop back to AT&T's "bong"?

I'd be intersted to see this thread continue as there are some real
business applications for my company with this.


Thanks,

Rob Hall    Hong Kong

------------------------------

From: [e-mail]
Subject: Re: Cellular Phone Technology
Date: 10 Jan 1995 18:25:17 GMT
Reply-To: [e-mail]


In <[e-mail]>, [e-mail] (Stan Brown)
writes:

> Having recently acquired a cellular phone, I suddenly find
> myself curious about how the systems operate.  Could someone point
me

·
> to a good reference on the operation of cellular systems?  I am
> particularly interested in the technical side (not economics) of
> roaming, and follow me.

There was an FCC technical report describing the system. You might try
fishing around gopher.fcc.gov.

I do know that it was published in full in the federal register a few
years back. You can probably sneakernet it from your local library.


Wally Ritchie    Ft. Lauderdale, Florida

------------------------------

From: [e-mail] (Fernando Vicuna)
Subject: SS7 ISUP to SS7 TCAP Conversion
Date: 10 Jan 1995 10:01:41 -0300


I am looking for a provider of a solution to the following problem.
There is a telephone switch that accepts SS7 ISUP signalling, and I
have a computer that accepts SS7 CCITT TCAP signalling. Is there some
kind of gateway that can translate the information provided by ISUP
into a TCAP query? Do I have to look for a switch provider that
has a Service Switching Point (SSP)?

The interface I am looking for will be used to provide Intelligent
Network Services.  Does anybody have experience in IN?  Thanks for
your help.


Fernando Vicuna   [e-mail]

------------------------------

Date: 10 Jan 1995 11:18:32 -0500
From: Paul Hebert <[e-mail]>
Subject: Planning to Purchase a Voice Mail System


My company is doing research for selection of a voice mail system. We
have presentations scheduled with Octel and Centigram. Would anyone
have some technical or user related insight into these systems? We
have an NEC 2400 switch. Any interface issues we should be aware of?


Paul Hebert   MARKEM Corp
Keene, NH     [e-mail]

------------------------------

From: [e-mail] (Wayne Huffman)
Subject: Re: Video Servers
Date: 10 Jan 1995 11:38:45 GMT
Organization: Netcom


In <[e-mail]> [e-mail] (Alwin Mulder)
writes:

> I am a graduation student at the University of Technology at
> Eindhoven, and I am working on a VOD project. I was wondering if
> anybody could tell me where I could find some information on
> video-server-systems. Are there any specific newsgroups and/or
> WWW-pages?

I have found a new publication that may be of help to you. It is
called Interactive Week. It is new, but they have already had VOD
articles.  You can reach them at the following addresses:

http://www.interactive-week.com

or e-mail them at [e-mail]. I don't work for then but
I like the publication so far.


Wayne Huffman

------------------------------

Date: Tue, 10 Jan 1995 10:14:55 -0500
From: Fred R. Goldstein <[e-mail]>
Subject: Re: DQDB and SMDS


From: [e-mail]

> Can anybody explain to me what the difference and/or connection is
> between DQDB (Distributed-Queue dual-bus) and SMDS (Switched
> Multi-Megabit Data Service).

Interesting topic, since the two are easily confused.

DQDB is a "Metropolitan Area Network" defined by IEEE 802.6.  It
provides for a cell-based (48-byte payload, similar to ATM) data
transfer, shared media with arbitration (telco speeds, T1/E1/T3/E3/
SONET/SDH as intended PMDs), and a novel combination of MAC services.
It has a "connectionless" service that resembles any LAN (long
variable-length packets) and an "isochronous" service that resembles
circuits (fixed-bandwidth channels).  DQDB was invented by Australians
(QPSX Comms. is its promoter) but never really caught on in a big way.

SMDS is a connectionless packet-switched public network service
developed by Bellcore.  It uses E.164 (ISDN/telephone numbers) for
addresses, allows long (9KB?) packets, etc.

When SMDS was being invented, DQDB was hot, so Bellcore specified that
the data link layer of SMDS would be the DQDB protocol.  This is "SIP
layer 2" and part of "SIP layer 3".  Thus it is possible to implement
SMDS using DQDB multiport bridges.  This is done in some places.  In
effect, SMDS is a service that DQDB delivers using a subset of its
capabilities.

In American practice, most users do not accept DQDB's odd cell-based
datalink, so SMDS now usually uses the "DXI" format, which maps SIP3
packets into HDLC frames.  Some DQDB vestiges (packet header, trailer)
remain but it's really just a packet service now.


Fred R. Goldstein     [e-mail]
Bolt Beranek & Newman Inc.  Cambridge MA
USA [phone]

------------------------------

From: [e-mail] (Russell Nelson)
Subject: Re: Source Code For Audio-Voice Modem Programming?
Date: 10 Jan 1995 15:30:07 GMT
Organization: Crynwr Software


In article <[e-mail]> System Operator
<system@decode.
com> writes:

> I'm looking for any sample or public domain source code used to
> control an audio-voice (AT+FCLASS 8) modem used in any kind of
> interactive application.

> Any pointers to FTP sites, etc, would be appreciated.

mgetty+sendfax works with ZyXEL (and possibly ZOOM and Rockwell-voice-
chip)
modems.  It works on various unices -- I use it on Linux.  Look for it
on ftp.leo.org.


russ <[e-mail]>    http://www.crynwr.com/crynwr/nelson.html
Crynwr Software   | Crynwr Software sells packet driver support | ask4
PGP key
11 Grant St.      | [phone] (9201 FAX)  | What is thee doing
about it?
Potsdam, NY 13676 | What part of "Congress shall make no law" eludes
Congress?

------------------------------

From: [e-mail] (TELECOM Digest Editor)
Subject: Biographies/Sketches of Our Participants
Date: Tue, 10 Jan 1995 14:00:00 CST


The results to date have been pretty positive. Many of you have
written
to say you would like to see a section in the Telecom Archives for the
biographies or 'thumbnail sketches' of the people who participate in
this
forum from day to day. So ... I've set it up.

It is located in the Telecom Archives at lcs.mit.edu. It is *not*
available
to FTP/Gopher/WWW readers. It is only available/readable via the
Telecom
Archives Email Information Service with the PASSWORD command. You get
the
current password when your entry has been received, reviewed and
installed.
In other words, install your own, then you get to read the others.
These
items will not be published in the Digest. It will be up to you from
time
to time to get a new 'index' of the biographical files on line to
select
the ones you want to read.

What would be appropriate?  Your name, address and phone number if you
wish to include it; a paragraph so so about your education and past or
present employment; if you have published anything you might want to
mention that as well. If you have a .signature file you are
particularly
proud of you can include that. Altogether, maybe 150-200 words or so
in
a couple paragraphs.

Please note that a log of activity for the Telecom Archives Email
Information
Service is available to me on a daily basis; particularly of interest
are
those requests to the server which invoke the PASSWORD command. I'll
send
full instructions for accessing the biography files to each person who
submits one, and remember, these are closed files available only to
the
people who wish to participate. Please report *any* abuses to my
attention.
By and large, snoopers, name-/list-gatherers won't have access.

Send your submissions to '[e-mail]' -- not to the Digest.


Thanks,

PAT

------------------------------

End of TELECOM Digest V15 #23
*****************************